Early last year I thought it was fun to rise to the challenge of creating a visual (designable) Web Part that could be deployed into the SharePoint 2010 Solution Sandbox. Mostly as a fun programming exercise and also because I wasn't sure how it could be achieved. In the end I got a pretty decent working solution that is now part of CKSDEV.

A while ago Microsoft also released a set of productivity extensions for the SharePoint sandbox. The PowerTools contain two new features; sandboxed compilation and… a Visual Web Part. Both features are also present in CKSDEV> A duplication which is best avoided. The CKSDEV team quickly decided to drop our versions in favor of Microsofts. Being the author of both features I want to go over the differences between the two and the reasoning behind dropping our features.

(Note that we only drop the template needed to create new sandboxed Web Parts, existing code will remain to work)

Sandboxed compilation

The motivation for this feature in CKSDEV was to provide additional compile-time information because certain methods are not available in the sandbox and normal compilation still allows you to call the unavailable code. My approach sucks a bit. It is only partly integrated into Visual Studio. When you hit 'Compile for Sandbox' the project references are updated to point to the sandboxed object model, a compile is forced and next the references are put back into place. This means you have to check out the project for this to work, and it modifies your project too. (It did only take a few lines of code thoughJ)

The Microsoft approach is integrated much further into the build process of Visual Studio. No fussing with swapping project references. All in all it is a much cleaner model. When you compile it either compiles against the sandbox or it compiles normally, depending on project settings. It also enables the red squiggly lines that appear as you type your code to indicate something will not compile when you would hit F5. This is something that we as the CKSDEV team cannot achieve with the current approach. So, Microsoft's version clearly wins in terms provided level of functionality. Luckily, we only have to remove our button and drop the code. There are no runtime dependencies within your actual projects.

Sandboxed Visual Web Part

This one is a bigger story. Both CKSDEV and the PowerTools provide their own template for creating a Sandboxed Visual Web Part. There is only one similarity in the approach. Both versions have no runtime requirement for including our DLLs. Everything you need is either generated or typed by you, but that is pretty much it. Let me begin with explaining how the CKSDEV version works (which was first to hit the market! They'll never take that away from me J).

Basically both approaches parse the ASCX file when you save it, and the generated code is added to your project. That way parsing does not take place at runtime outside of the sandboxed environment.

One of the biggest challenges for CKSDEV was to find a way to parse a User Control (ASCX) file and push the generated code into the project. The ASP.NET User Control parser is hidden from the public so calling it directly is not an option. There are a few ways to work around this issue. The workaround applied by CKSDEV was to call the aspnet_compiler.exe tool with the –debug flag. This forces the code generation to take place, obviously with too details like line pragma's and other unnecessary stuff. We then scoop up the generated code and push the code into the project. The overall code structure resulting from this approach is shown in the following graphic. Blue means generated, green is stuff you type.

Lots of blue stuff for little green stuff!

The Microsoft approach to parsing the ASCX is to use the ClientBuildManager class provided by ASP.NET. I also wanted to use this class but getting it to work exactly as I wanted involved lots of CodeDom and more work than I wanted to do. The ClientBuildManager is able to generate code into a CodeDom CodeCompileUnit which you then transform into code using an ICodeGenerator from .NET. This approach is more involved and requires the generated to be buffed and polished. We choose not to learn too much CodeDOM, but obviously that knowledge is already inhouse somewhere in Redmond. The structure is much different though. Since you get back a CodeCompileUnit (basically a parse tree) you can modify the tree to suite your needs. One cool effect the Microsoft approach then has is that your resulting code does not use the UserControl base class but directly creates a Web Part. The benefit is less classes to generate and maintain. The graphic is as follows.

The difference for you as a user of the template is primarily visible in the code-behind. For the CKSDEV approach the method that instantiates the generated controls is called automatically by the UserControl base class in the Init phase of the page lifecycle. For the PowerTools edition this method is called by you. Other notable differences is that the CKSDEV approach allows you to use <script runat="server"> blocks differently from the PowerTools. The reason for this is that the PowerTools use a single class and CKSDEV has a class hierarchy. Say that you use a script block to override the OnLoad method. If you do the same in the code-behind you'll have two methods with the same signature, going in the same class. For the CKSDEV version the OnLoad would be added in a different class and hence you can combine <script runat="server"> blocks with normal code-behind without thinking about it.

Supporting the CKSDEV Sandboxed Web Part

Given the fact that you may have already invested in the CKSDEV Sandboxed Web Part we are not happy to remove the feature. To ensure that we don't break your build we choose to keep the internal code in place, but we'll remove the Visual Studio template. This means you'll no longer have an easy time creating new CKSDEV Sandboxed Visual Web Parts, but the existing ones will keep on working as is. We do plan to provide a conversion tool to convert the CKSDEV version to the Microsoft version. But given the large differences in the approach there are a few technical difficulties that take a bit of time to overcome. (we'll for instance need to swap out your base class of UserControl in favor of WebPart). One thing that we'll not likely be able to achieve is a conversion tool that will not break existing deployed Web Parts, so there's still some discussing to be done how to handle that.

Hope this clarifies some of the differences between the PowerTools and the CKSDEV version. Of course CKSDEV will continue to provide you with much needed enhancements to the Visual Studio 2010 out of the box experience, these two will just not be part of that).

Did I say you should get CKSDEV RIGHT NOW! J